[WIP] Wii U memory map + .rpx hashing#515
Conversation
Jamiras
left a comment
Jamiras
left a comment
There was a problem hiding this comment.
I really don't feel like we're in a position to support Wii U at this time (or any time soon).
| { 0x90000000U, 0xF3FFFFFFU, 0x90000000U, RC_MEMORY_TYPE_UNUSED, "Unused" }, | ||
| { 0xF4000000U, 0xF5FFFFFFU, 0xF4000000U, RC_MEMORY_TYPE_VIRTUAL_RAM, "MEM1" } | ||
| }; | ||
| static const rc_memory_regions_t rc_memory_regions_wii_u = { _rc_memory_regions_wii_u, 5 }; |
There was a problem hiding this comment.
I saw Jamiras's previous concerns on the 3DS PR regarding the massive memory dumps, so I marked MEM1 as VIRTUAL_RAM and the Code segment as READONLY to restrict the default searchable pool strictly to the MEM2 block, not sure if much more can / needs to be done as of now.
Excluding the 32MB MEM1 while still including the 2048MB MEM2 doesn't really seem like it would help much. I've been very reluctant to proceed with the 3DS PR because it's trying to expose 1/3 as much memory as this PR does.
When a user presses "New Search", we ask the core/emulator for all the memory expected by the memory map. This gets saved in a snapshot so when the user presses "Filter", we can identify which memory values changed. With a 2GB+ initial snapshot, and large subsets of that for each step of filtering, the host system will very quickly run out of memory before the developer is able to find the data they're looking for.
| return rc_hash_iterator_buffer(hash, iterator); | ||
| } | ||
|
|
||
| int rc_hash_wiiu(char hash[33], const rc_hash_iterator_t* iterator) |
There was a problem hiding this comment.
Conceptually, this should be rc_hash_wiiu_rpx. Most users will expect support for wux files, and this function won't handle those.
Additionally, wux processing should be in hash_disc.c, so there shouldn't be a common function that tries to support both.
There was a problem hiding this comment.
Most users will expect support for wux files, and this function won't handle those.
Fully parsing WUD/WUX inside hash_disc.c would require rcheevos to implement Wii U AES decryption and manage proprietary keys files, which feels a bit out of scope (from what I understand)
Maybe we could bypass this and fully support .wux files without bloating this repo by letting Cemu handle the heavy lifting, since it already decrypts and extracts main.rpx into RAM. We could theoretically pass the buffer directly to rc_hash_generate_from_buffer() from there.
With that, rcheevos would only ever need to know how to hash a .rpx payload, no matter what file type was initially passed.
That being said, I understand that it's easier said than done, and may not fit what you envision for the project, but I just wanted to leave that there as an idea for future implementations.
Yeah, I figured by looking at other parts of the project later on. I'll proceed with the requested changes and leave this PR as a Draft/reference. I hope it will be helpful when the team is ready to tackle this generation of consoles :) |
2 participants
I have mapped the Wii U virtual memory based on Cafe OS specifications and verified the bounds against Cemu's open-source allocator (
coreinit_Memory.cpp).0x10000000->RC_MEMORY_TYPE_SYSTEM_RAM0xF4000000->RC_MEMORY_TYPE_VIRTUAL_RAM0x01000000->RC_MEMORY_TYPE_READONLYI saw Jamiras's previous concerns on the 3DS PR regarding the massive memory dumps, so I marked MEM1 as
VIRTUAL_RAMand the Code segment asREADONLYto restrict the default searchable pool strictly to the MEM2 block, not sure if much more can / needs to be done as of now.I also implemented the ELF parser in
hash_rom.cto identify and hash.rpxexecutables, along with custom unit tests.Let me know if I should change something, I tried to follow the baseline set with previous functions and methods, hope this will be useful !